Steps to Resolve the Database JAVAVM Component if it Becomes INVALID After Applying an OJVM Patch
11.2.0.2升级到11.2.0.4 memory_target 设置过小，只有800M。 导致jserver jave virtual machine 组件无法安装，
建议升级之前至少memory_target调大到2000M。保证 JAVA_POOL_SIZE = 150M; 升级完成之后，可以memory_target调小到800m .
GOAL
Since the new Oracle JVM PSU patching scheme for 11.2.0.3, 11.2.04, and 12c databases, more and more customers are finding that their Database JVM Component is showing up as INVALID. The goal of this document is to help resolve the most common cases.
1) ORA-29548 classes.bin mismatched in binaries and database
2) ORA-29516: Aurora assertion failure: Assertion failure at eox.c:359 java.lang.UnsatisfiedLinkError sun.net.PortConfig.getLower0
3) ORA-00600:[26599][1][195]
SOLUTION
The Oracle DB JVM is comprised of 2 parts
1. Binaries (opatch) and
2. Database objects (11g postinstall.sql/12c datapatch).
When applying a patch that affects the Oracle Database JVM, one must make sure that both pieces get patched and are in SYNC or the JVM will be unusable. A broken JVM will then cause problems not only for custom Java Stored Procedure applications but also for other database components such as XDB and SDO that depend on it.
Most of the time, the post installation step (postinstall.sql or datapatch) was not run or did not get run properly. The next most likely scenario is that there was some hiccup that caused the binaries to not get relinked with the changes. And finally, on rare occasions and only on some 12c OJVM PSUs, the JDK version needs to be manually upgraded.
Steps to Resolve :
Test the JVM installation by running -
select dbms_java.get_jdk_version() from dual; -- for 12.1
If this returns an ORA-29548, then:
Follow the readme guidelines from the OJVM PSU patch installed and follow post installation instructions to run either postinstall.sql or datapatch. Afterwards, run utlrp.sql.
If the jvm is still invalid or the error was ORA-29516, then relink the binaries using 'make -f ins_rdbms.mk ioracle' from the OH/rdbms/lib directory.
If you are using 12c and the the JVM is still invalid, then run
and retest the installation using:
If you get here and the JVM is still invalid, then use the brute force method to remove the JVM and reinstall it.
JVM Removal and Reinstall steps
For the most part, these steps should be executed one by one rather than in a single script.
1. Connect as SYSDBA and startup the database in restricted mode.
NOTE: The following procedure can be performed while users are accessing the database. However, care should be taken to insure that no one is executing any Java or XML code inside the database. If in doubt, then shutdown and startup the database in restricted mode using the following startup steps.
***NOTE: A restart of the database is required at the end regardless of whether you are in restricted mode or not***
connect / as sysdba
startup mount
alter system set "_system_trig_enabled" = false scope=memory;
alter system enable restricted session;
alter database open;
2. Start a log of the session so that any problems encountered can be investigated later.
spool force_removal.txt
set echo on
3. Execute version specific scripts one at a time.
SQL> @?/rdbms/admin/catnoexf.sql
SQL> @?/rdbms/admin/catnojav.sql
SQL> @?/xdk/admin/rmxml.sql
4. Next is the part which actually removes the JVM objects from the database.
A value of TRUE removes ALL objects.
A value of FALSE leaves user java objects intact.
If you are concerned about losing user java objects then try running the procedure with a value of FALSE. However, it should be noted that many times this still leaves the database in a state where JVM can not be successfully reinstalled.
execute rmjvm.run(false); -- Use true if false does not fix the problem but be aware
truncate table java$jvm$status;
delete from obj$ where obj#=0 and type#=0;
commit;
set echo off
spool off
5. Now you must shutdown and restart the database in mount mode
***VERY IMPORTANT***
You must shutdown and restart the database at this point in order to remove and remaining traces of JVM from memory. This is especially important if you will be reloading JVM. If you do not restart the database then a subsequent reload will fail.
6. Now reload the JVM using the following INSTALL steps below from a new SQL*Plus session:
-- connect / as sysdba
spool full_jvminst.log;
set echo on
alter system set "_system_trig_enabled" = false scope=memory;
alter database open;
@?/javavm/install/initjvm.sql
@?/xdk/admin/initxml.sql
@?/xdk/admin/xmlja.sql
@?/rdbms/admin/catjava.sql
shutdown immediate
set echo off
spool off
exit
IMPORTANT NOTES
If the initjvm.sql script errors with an ORA-955 error executing the "create or replace java system" command, then see the following note on Metalink for details on how to resolve this.
Note 276457.1 How to Resolve ORA-955 Errors When Running initjvm.sql
7. Review the log file FULL_JVMINST.LOG
Review the log file and check to see if any unexpected errors were raised.
8. Resolve Invalid Objects
Be sure the JVM INSTALL steps completed successfully and restart the database instance
Once the database has been started, resolve any invalid objects by running the utlrp.sql script:
9. Validate the Install
The JVM should now be fully installed.
Execute the following validation queries to retrieve the final count of SYS Java Objects inside the database:
-- Validation Query 1
select count(*), object_type
from all_objects
where object_type like '%JAVA%'
and owner = 'SYS'
group by object_type;
-- Validation Query 2
select owner, count(*)
from all_objects
where object_type like '%JAVA%'
and owner = 'SYS'group by owner;
-- Validation Query 3
select owner, object_type, count(*)
from all_objects
where object_type like '%JAVA%'
and status <> 'VALID'
and owner = 'SYS'
group by owner, object_type;
